Data communication in a computer internetwork involves the exchange of data between two or more entities interconnected by communication links and networks. These entities are typically software programs executing on hardware computer platforms, such as end stations and intermediate stations. An example of an intermediate station may be a switch or router which interconnects the communication links and networks to enable transmission of data between the end stations.
Communication software executing on the end stations generally correlate and manage data communication with other end stations. The stations typically communicate by exchanging discrete packets or frames of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the stations interact with each other. In addition, network routing software executing on the routers allow expansion of communication to other end stations. Collectively, these hardware and software components comprise a communications network and their interconnections are defined by an underlying architecture.
Modern communications network architectures are typically organized as a series of hardware and software levels or "layers" within each station. These layers interact to format data for transfer between, e.g., a source station and a destination station communicating over the network. Predetermined services are performed on the data as it passes through each layer and the layers communicate with each other by means of the predefined protocols. An example of such a communications architecture is the Internet communications architecture.
The Internet architecture is represented by four layers which are termed, in ascending interfacing order, the network interface, internetwork, transport and application layers. These layers are arranged to form a protocol stack in each communicating station of the network. FIG. 1 illustrates a schematic block diagram of prior art Internet protocol stacks 125 and 175 used to transmit data between a source station 110 and a destination station 150, respectively, of a network 100. As can be seen, the stacks 125 and 175 are physically connected through a communications channel 180 at the network interface layers 120 and 160. For ease of description, the protocol stack 125 will be described.
In general, the lower layers of the communications stack provide intemetworking services and the upper layers, which are the users of these services, collectively provide common network application services. The application layer 112 provides services suitable for the different types of applications using the network, while the lower network is interface layer 120 utilizes industry standards defining a flexible network architecture oriented to the implementation of local area networks (LANs) and wide area networks (WANs).
Specifically, the network interface layer 120 comprises physical and data link sublayers. The physical layer 126 is concerned with the actual transmission of signals across the communication channel and defines the types of cabling, plugs and connectors used in connection with the channel. The data link layer (i.e., "layer 2") is responsible for transmission of data from one station to another and may be further divided into two sublayers: Logical Link Control (LLC 122) and Media Access Control (MAC 124). The LLC sublayer 122 is responsible for providing connectionless or connection-oriented communication services, while the MAC sublayer 124 is responsible for layer 2 addressing and controlling access to the transmission medium.
The transport layer 114 and the internetwork layer 116 are substantially involved in providing predefined sets of services to aid in connecting the source station to the destination station when establishing application-to-application communication sessions. The primary network layer protocol of the Internet architecture is the Internet protocol (IP) contained within the internetwork layer 116. IP is primarily a connectionless network protocol that provides internetwork routing, fragmentation and reassembly of datagrams and that relies on transport protocols for end-to-end reliability. An example of such a transport protocol is the Transmission Control Protocol (TCP) contained within the transport layer 114. Notably, TCP provides connection-oriented services to the upper layer protocols of the Internet architecture. The term TCP/IP is commonly used to refer to the Internet architecture which is further described in Computer Networks by Andrew S. Tanenbaum, printed by Prentice Hall PTR, Upper Saddle River, N.J., 1996.
Data transmission over the network 100 therefore consists of generating data in, e.g., sending process 104 executing on the source station 110, passing that data to the application layer 112 and down through the layers of the protocol stack 125, where the data are sequentially formatted as a frame for delivery onto the channel 180 as bits. Those frame bits are then transmitted over an established connection of channel 180 to the protocol stack 175 of the destination station 150 where they are passed up that stack to a receiving process 174. Data flow is schematically illustrated by solid arrows.
Although actual data transmission occurs vertically through the stacks, each layer is programmed as though such transmission were horizontal. That is, each layer in the source station 110 is programmed to transmit data to its corresponding layer in the destination station 150, as schematically shown by dotted arrows. To achieve this effect, each layer of the protocol stack 125 in the source station 110 typically adds information (in the form of a header) to the data generated by the sending process as the data descends the stack.
For example, the internetwork layer encapsulates data presented to it by the transport layer within a packet having an internetwork layer header. The internetwork layer header contains, among other information, source and destination (logical) network addresses needed to complete the data transfer. The data link layer, in turn, encapsulates the packet in a frame that includes a data link layer header containing information required to complete the data link functions, such as (physical) MAC addresses. At the destination station 150, these encapsulated headers are stripped off one-by-one as the frame propagates up the layers of the stack 175 until it arrives at the receiving process.
FIG. 2 is a schematic diagram of a conventional airline reservation system 200 that comprises a plurality of components including a host reservation system (HRS) 250. Users, such as reservation agents, access the HRS through display terminals 202 and printer terminals 204 connected to an agent set control unit (ASCU 210). The ASCU 210 is coupled to a network cloud 220 via a branch network interface system (NIS) 214; the ASCU functions as a communications controller between the network and terminals. A gateway 206 may be present downstream of the NIS 214 to provide high-level protocol conversion (i.e., higher than layer 2). The gateway 206 interfaces to a local area network (such as a token ring 208) having devices 205 coupled thereto; this arrangement enables a TCP/IP session between the gateway and a device as typically occurs in an airport where the gateway functions as an airport services gateway.
Communication between the branch NIS 214 and ASCU 210 or gateway 206 involves the exchange of data frames using character-oriented protocols, such as the IBM airline control (ALC) protocol or the Unisys terminal system (UTS) protocol. The ALC protocol (such as P1024B) is typically used to communicate with an IBM mainframe computer functioning as the HRS 250, whereas the UTS protocol (such as P1024C) is generally used to communicate with a Unisys computer system functioning as the HRS. The P1024 terminology originates from the Societe International de Telecommunications Aeronautiques (SITA) which is an international company (e.g., a service provider) for the airline reservation systems that provides, inter alia, the NISs 214. For ease of description, the ALC protocol will be used hereinafter as an example of the character-oriented protocol.
The branch NIS 214 receives the ALC frames and locally terminates the protocol by encapsulating the frames for transmission over the network 220 to a data center NIS 224. The data center NIS then forwards the data message from the network 220 to the HRS 250 over a communication link employing virtual circuits associated with, e.g., an Airline X.25 (AX.25) protocol or an Exchange of Mixed Traffic over X.25 (EMTOX) protocol. An example of an HRS 250 is an IBM mainframe computer executing a Transaction Processing Facility (TPF) operating system in support of various reservation application programs executing on the mainframe. The TPF mainframe is typically channelattached to an IBM 3745 (or 3725) front end processor (FEP) running an NCP application program. The HRS 250 creates a response to the data message and sends that response to the data center NIS over either an AX.25 or EMTOX virtual circuit. The data center NIS forwards the message over the network cloud 220 to the appropriate branch NIS 214 which, in turn, forwards this message to the appropriate ASCU 210 for output on the display terminal 202 or printer terminal 204.
A problem with the conventional reservation system network involves correlation between ASCUs and AX.25/EMTOX virtual circuits when transporting data messages over the network 220 between the terminals and the HRS. When the branch NIS 214 receives a message from an ASCU 210 and forwards the data over the network 220, the data center NIS 224 must be able to select the correct AX.25 or EMTOX virtual circuit for forwarding the data to the HRS. Similarly when the HRS 250 sends a message to a user, the data center NIS must forward the message to the correct branch NIS which, in turn, must forward the message to the correct ASCU.
This problem is currently solved by using X.25 as the backbone networking protocol between the branch NIS 214 and the data center NIS 224. The X.25 protocol is a conventional layer 3, connection-oriented protocol that employs virtual circuits. Data messages are transported between the HRS and the terminals over these X.25 virtual circuits, which are typically Switched Virtual Circuits (SVCs). Connection establishment of an X.25 SVC comprises the exchange of conventional X.25 Call and Call Confirm messages/packets. An SVC can be established and brought down dynamically within the context of an X.25 network and its data terminal equipment, such as the branch and data center NISs. A logical channel number (LCN) is assigned by the initiator (e.g., a branch NIS) of the SVC connection in the X.25 network and is used by the data center NIS to correlate the X.25 SVC with an appropriate EMTOX or AX.25 virtual circuit. The details of X.25 virtual circuit connection establishment and termination are well-known and, thus, will not be described herein.
The AX.25 protocol is generally the same as the X.25 protocol with the exception that it employs a non-standard packet size of 240 bytes rather than conventional X.25 packet sizes of 128 bytes, 256 bytes or 512 bytes and that it utilizes permanent virtual circuits (PVCs) rather the SVCS. A PVC generally requires no Call set-up procedures for the connection between data center NIS and the HRS because that connection is technically "never" destroyed. EMTOX, on the other hand, is a specification for transmitting airline protocol data over standard X.25 SVCs.
The branch NIS may further associate a single SVC with each ASCU or with a group of ASCUs using ASCU identifiers that are passed within user data fields of Call and Call Confirm packets when establishing the X.25 SVC. The ASCU identifier identifies each ASCU to the HRS by two 1-byte values A1 and A2. Collectively, A1 and A2 provide a 2-byte representation (2.sup.16) of ASCUs to the host; however, the ASCUs recognize themselves via a 1-byte interchange address (IA) value. The 2-byte A1/A2 value is prepended to each data message to identify the ASCU associated with the message.
In such an X.25 network environment, the branch NIS 214 may be a terminal protocol assembler-disassembler (TPAD) device that functions as a protocol converter to transfer ALC data messages over the network. Thus, the messages are converted by TPAD into an X.25 format and transported over one or more SVCs through the X.25 network cloud and onto the data center NIS 124, which may be a host protocol assembler-disassembler (HPAD) device. The TPAD device may establish an X.25 SVC directly with the FEP of the TPF system using the EMTOX protocol, i.e., without the assistance of the HPAD device. X.25 traffic support within the NCP program is provided via an NCP packet switching interface (NPSI) software program. However, the HPAD is needed to interface an X.25 SVC to an AX.25 link because the AX.25 protocol is non-standard and utilizes PVCs. The AX.25 PVC connection has an assumed LCN that the HPAD uses to associate the connection with an appropriate X.25 SVC.
FIG. 3 is a schematic block diagram of a data frame 300 having a format defined by the ALC protocol. The ALC frame format comprises a first 1-byte synchronization (SYNC 1) field 302, a second 1-byte synchronization (SYNC 2) field 304, a 1-byte interchange address (IA) field 306, a 1-byte terminal address (TA) field 308, an n-byte text (TXT) field 310 containing user data, a 1-byte end-of-message (EOM) field 312 and a 1-byte Cyclical Check Character (CCC) field 314 that is used to perform error checking on the frame. Note that the fields 306-312 comprise an I-field 320.
A terminal 202 sends a text data message to ASCU 210 which generates the ALC data frame 300 and transmits it to TPAD 214. TPAD processes the frame to create a conventional frame format 400, shown in FIG. 4, for transmission over the X.25 network. TPAD 214 parses the frame 300 to remove the SYNC bytes 302, 304 and replaces the contents of the IA field 306 with the A2 value in field 402 of the ASCU identifier; the A1 is value is then prepended to the parsed frame as an ASCU identification header 404. The TPAD device is pre-configured with translation information used to perform a mapping operation between the IA field contents and the A1/A2 values inserted into the parsed frame.
TPAD then prepends an X.25 protocol field 406 along with a Link Access Protocol B (LAPB) field 408, whose content describes a data link control (DLC) protocol that provides a reliable connection between TPAD and a switch of the X.25 network. A Frame Check Sequence (FCS) field 410 is also appended to the LAPB frame 400 to ensure the accuracy of the information contained within the frame. The FCS field is a 2-byte field that may encapsulate, inter alia, the CCC field 314, although in some embodiments the CCC field may be removed. LAPB encapsulation provides separate LAPB sessions between X.25 switches. The DLC protocol thereafter enables multiplexing of a plurality of X.25 virtual circuits over a single LAPB session. However, this encapsulation technique is generally restricted to operations over an X.25 network.
The LAPB frame 400 is forwarded over an X.25 SVC from the TPAD to HPAD, which forwards it over an appropriate AX.25 or EMTOX virtual circuit specified by a configured or "learned" LCN correlator. The LAPB frame format 400 remains generally in tact for the EMTOX protocol embodiment, but for the AX.25 protocol embodiment, the HPAD effectively reconfigures the segment size of the data transferred over the link to the HRS. For example, a 500-byte frame, representing the I-field 420 of the LAPB frame, is segmented into four 128-byte frames for transmission over the X.25 network. Upon receiving the four frames, HPAD combines them into three 240-byte frames for transmission over the AX.25 link.
In either embodiment, the ASCU identifiers are maintained so the HRS can determine the ASCU from which the message originated. When the HRS sends a response to the user, it also prepends the ASCU identifier to the message. Based on the AX.25 or EMTOX virtual circuit LCN (and possibly the ASCU identifier), the HPAD forwards the message over an X.25 SVC to the TPAD, which inspects the ASCU identifiers to determine the correct ASCU to receive the message.
Although the current solution works well for X.25 networks, it does not generally work for other WAN backbone protocols such as Frame Relay or ATM unless the X.25 SVC is "tunneled" over that backbone protocol. Service providers for airline reservation systems generally prefer interoperating with a common IP backbone over Frame Relay, ATM or X.25 so that other revenue-generating network services may be offered. Frame Relay is a layer 2 protocol that generally "switches" frames across the network in a connection-oriented manner; although there are some SVC implementations of Frame Relay, that protocol is primarily PVC-oriented. For example, when a branch NIS communicates with a data center NIS over a Frame Relay network, the Frame Relay network administrator is notified and a PVC is established between the two entities. In addition, customers generally prefer utilizing an IP backbone to the HRS.
RFC 2351 describes Mapping of Airline Traffic over IP (MATIP) which is a system for transporting reservation system data over a TCP session on a TCP/IP network. Any WAN media over which the IP protocol can be transported (such as Frame Relay or ATM, instead of just X.25) can be used by MATIP. However, the TCP session endpoints in such an environment reside within the branch NIS and the HRS. A typical HRS system does not generally have a TCP/IP protocol stack, thereby requiring use of a different processor in the HRS. In addition, although MATIP is layered over TCP/IP, it does not support multiplexing of multiple MATIP circuits over a TCP session and, as a result, requires a one-to-one correlation between a MATIP virtual circuit and a TCP session.
Therefore, an object of the present invention is to provide a system for transporting airline reservation data over a TCP/IP network.
Another object of the present invention is to provide an encapsulation technique for data messages that provides correlation between ASCUs and AX.25/EMTOX virtual circuits bordering a TCP/IP network.
Another object of the present invention is to provide a technique for limiting the number of TCP sessions used to transport airline reservation data over a TCP/IP network to thereby reduce overhead and consumption of resources in the network.